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CONNECTIVITY  FOR  THE  HIGHLY  DYNAMIC  VEHICLES 
IN  A  REAL  AND  SYNTHETIC  ENVIRONMENT  (HYDY)  PROJECT 

Kevin  E.  Boner 

Naval  Command,  Control  and  Ocean  Surveillance  Center.  RDT&E  Division 

San  Diego,  California 


INTRODUCTION 

The  Advanced  Research  Projects  Agency  (ARPA) 
has  created  the  Intelligent  Gateway/Scaleable  Sim¬ 
ulation  (IGSS)  project  to  perform  research  into 
problems  associated  with  large-scale  simulations, 
combining  both  real  and  simulated  units  on  Local 
Area  Networtcs  (LANs)  and  Wide  Area  Networks 
(WANs).  The  program’s  goal  is  to  achieve  seamless 
simulation  by  providing  woridwide  access  to  multi¬ 
layer  simultaneous,  realtime,  very  large  virtual  war¬ 
fighting  environments  composed  of  1 0,000  or  more 
objects.  Seamless  simulation  requires  user- 
friendly,  self-configuring,  variable-scale  environ¬ 
ments  with  essential  resolution,  and  transparent 
connectivity.  The  IGSS  program's  intent  to  research 
-areas  of  potential  difficulty  resulted  in  the  selection 
ofthe  following  subprojects;  (1)  Integration  of  highly 
dynamic  live  objects  with  synthetic  objects;  (2) 
interoperability  of  coarse  grain  (e.g.,  time  step  war- 
games/aggregate  units)  with  fine  grain  (realtime/ 
individual  units)  simulations;  (3)  interoperability  of^ 
engineering  fidelity  sirhulators  with  moderate  fidel-^ 
ity  simulators;  and  (4)  networking  of  large  numbers 
of  objects  (10,000  to  100,000)  into  one  simulated 
warfighting  environment. 

An  Advanced  Interface  Unit  (AlU)  will  be  developed 
to  provide  capabilitiesAools  for  simulators  and  real 
systems  to  use  in  interfacing  with  the  warfighting 
network. 

This  effort,  called  Highly  Dynamic  Vehicles  (HYDY), 
Phase  I,  resulted  in  a  Proof-of-Concept  (POC)  dem¬ 
onstration  showing  the  feasibility  of  integrating  a 
live  F-1 4D  aircraft  into  the  simulation  environment. 
Network  connectivity  was  established  between  (1) 
an  existing  airaaft  simulation  facility  located  at  the 
Naval  Air  Warfare  Center  Aircraft  Division  (NAW- 
CAD)  Manned  Flight  Simulator  (MFS)  in  Patuxent 
River,  MD;  (2)  the  Naval  Air  Warfare  Center  Weap¬ 
ons  Division  (NAWCWD)  System  Integration  Test 
Station  (SITS)  in  Pt.  Mugu,  CA;  and  (3)  the  Secure 
Integration  Simulation  Laboratory  (SISL)  located  at 
the  Naval  Command,  Control  and  Ocean  Surveil¬ 
lance  Center  (NCCOSC)  Research,  Development, 
Test  and  Evaluation  (RDT&E)  Division  in  San 
Diego,  CA. 


OVERVIEW 

This  paper  provides  a  general  discussion  of  the 
effort  to  connect  the  three  facilities  (MFS,  SITS, 
SISL),  the  modification  made  to  those  facilities  to 
support  this  project,  the  connectivity  established 
between  and  within  the  facilities,  problems  encoun¬ 
tered,  lessons  learned,  and  the  results  of  the  HYDY 
Phase  I  POC  demonstration. 

The  culmination  of  this  effort  will  allow  a  live  aircraft, 
while  in  flight,  to  interact  Beyond  Visual  Range 
(BVR)  with  simulated  aircraft  (e.g.,  man  simula¬ 
tors).  This  interaction  will  result  from  stimulation  of 
the  aircraft’s  radar  and  Radar  Warning  Receiver 
(RWR)  based  on  an  interchange  of  information 
between  the  simulated  unit(s)  and  the  live  aircraft. 
The  interchange  will  use  ground  communication  of 
Protocol  Data  Units  (PDUs)  formatted  in  accor¬ 
dance  with  the  Simulation  Training  and  Instrumen¬ 
tation  Command  (STRICOM)/ARPA  draft  military 
standard  for  a  Distributed  Interactive  Simulation 
(DIS)  protocol  and  radio  frequency  (RF)  commu¬ 
nication  usjng^  the  "express  PDUs."  Based  on 
informatioh're<%ived  in  the  PDUs,  the  radar  and 
RWR  will  be  stimulated.  For  this  demonstration  DIS 
PDUs  were  transmitted  via  ground-based  commu¬ 
nications  facilities  at  the  three  sites  specified  above. 

This  effort  demonstrated  the  ability  to  utilize  DIS 
standard  PDUs  with  HYDY  vehicles  (DIS  entities) 
over  a  LAN  and  WAN  by  using  one  (or  two)  of  these 
DIS  entities  to  stimulate  an  active  radar  (APG-71) 
that  was  simultaneously  receiving  real  aircraft 
returns.  The  challenge  was  to  stimulate  the  radar 
such  that  the  real  and  simulated  returns  were  indis¬ 
tinguishable  from  each  other. 

FACIUTY  AND  HARDWARE  DESCRIPTIONS 

Systems  Integration  Test  Station  (SITS) 

The  SITS  facility  develops,  tests,  integrates,  veri¬ 
fies,  and  validates  flight  software  for  the  F-14D 
fighter  aircraft  and  provides  a  ground-based  site  for 
development  and  test  of  modifications  required  to 
allow  injection  of  simulated  air  targets  into  the  radar 
for  display  on  cockpit  display  consoles.  SITS  con¬ 
tains  the  front  section  of  an  F-1 4D  with  all  of  the 
operational  flight  computers,  the  complete  radar 
system,  and  a  full  cockpit.  This  partial  airframe’s 
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location  allows  the  radar  to  be  turned  on  and  detect 
real  aircraft  flying  on  the  NAWCWD  test  range.  A 
Radar  Target  Stimulator  (RTS)  allows  the  injection 
of  computer-generated  targets  into  the  radar  sys¬ 
tem  while  detecting  live  targets  on  the  range.  There¬ 
fore,  a  live  F-1 4D  radar  could  be  stimulated  from  a 
simulation  network  by  modification  of  the  RTS  sys¬ 
tem,  which  would  cause  it  to  accept  DIS  PDUs  as 
definitions  of  the  targets  it  should  inject  into  the 
F-1 4D  radar  system.  The  software  is  described  in  a 
later  section. 

SITS  hardware  connectivity  starts  with  a  local  Navy 
Network  (NAVNET)  node  (T1  tail  circuit).  NAVNET 
is  a  long  haul  T1  (1.544-million-bits-per-second 
[MBPS])  network  with  nodes  located  at  various 
sites.  The  local  NAVNET  node  feeds  a  56-thou- 
sand-bits-per-second  (KBPS)  tail  circuit  into  the 
SITS  facility.  The  hardware  connection  inside  the 
facility,  from  modem  to  F-14D  airframe,  is 
described  in  the  following  paragraphs. 

Network  Hardware  Conrtectivity.  Network 
connectivity  consists  of  the  following  equipment 
required  to  bring  the  DIS  PDUs  to/from  the  AlU; 


(1)  A  Codex  2172  Modem  configured  to  operate 
at  56  KBPS  connects  the  NAVNET  tail  circuit 
to  a  KG-84A. 

(2)  A  KG-84A  point-to-point  data  cryptographic 
device  connects  to  the  modem  by  a  V.35  to 
RS-422  cable  and  a  RS-422  to  MIL- 
STD-188C  Minimate  connector.  The  V.35 
connects  to  the  modem  while  the  MIL- 
STD-188C  connects  to  the  "Black” 
(encrypted)  connection  on  the  KG-84A. 

(3)  A  TIMEPLEX  Minilink  unit  provides  the  link 
between  "phone"  and  computer  communica¬ 
tions.  This  unit  is  connected  to  the  KG-84A 
"Red"  (decrypted)  connection  by  an  MIL- 
STD-188C  to  RS^22  Minimate  connector 
and  a  RS-422  to  RS-422  cable. 

(4)  A  RAD  REB-1 0  ethemet  bridge  provides  for  a 
dedicated  thick  ethemet  line  to  the  AlU.  This 
unit  is  connected  to  the  Minilink  via  an  RS-422 
cable. 
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AlU  Hardware  Connectivity.  The  AlU  is 
responsible  for  the  network  interface,  the  managing 
of  DIS  PDUs  and  the  interface  to  the  host,  a  VAX 
8600  described  in  the  next  section.  The  AlU  con¬ 
sists  of  a  Force  CPU-40  processor  board  and  an 
laon  DR11-W  emulator  board,  both  residing  in  a 
VME  card  cage.  The  AlU  is  connected  to  the  ether- 
net  bridge  via  a  thick  ethernet  cable.  The  DR11-W 
is  connected  to  the  VAX  8600  by  two  1 6-pin  flat  rib¬ 
bon  cables;  one  for  input  and  one  for  output  of  data. 

The  AlU  also  provides  a  simple  PDU  generation 
feature  that  allows  the  operator  to  cause  the  device 
to  output  PDUs  to  itself  and  to  the  network  that  rep¬ 
resents  an  aircraft.  This  aircraft  can  be  maneuvered 
interactively  by  the  operator. 

Radar  Target  Simulator  Hardware  Connec¬ 
tivity.  The  RTS  hardware  connectivity  includes  a 
'  VAX-8600  intertecing  Unit,  the  RTS  system,  and 
Airframe  Interfadng  Unit.  These  three  “units"  are 
descnbed  as  follows: 

(1 )  The  VAX  8600  provides  the  interface  between 
the  AlU,  RTS  and  the  F-14D  airframe. 
Thus,the  AlU  receives  local  entity  data  from 
the  F-1 4D  airframe  interface  and  provides  the 
RTS  with  the  target  entity  data  received  from 
the  network  via  the  AlU,  The  VAX  converts 
state  information  from  DIS  worid  coordinates 
to  latitude  and  longrtude  and  vice  versa, 
compares  the  targefrframe  aspect  ratios  to 
generate  target  Radar  Cro^'  Sections  (RCS),  ^ 
and  formats  RCS  packet  data  to  be  sent  to  the 
RTS.  It  communicates  with  the  AlU  and  the 
airframe  interface  via  a  DR1 1  -W  interface  and 
with  the  RTS  by  “thin"  ethernet.  Each  OR1 1  -W 
interface  requires  two  1 6-pin  flat  ribbon  cables. 

(2)  The  RTS  primarily  consists  of  a  Hewlett  Pack¬ 
ard  HP-1000,  a  target  generator  diassis.  RF 
and  Intermediate  frequency  (IF)  interfrices, 
electronic  countemieasures  (ECM)  equip¬ 
ment,  and  an  IBM  386  persons  computer  for 
front-end  operator  interaction  and  display.  The 
RTS  provides  for  radarAarget  simulations  and 
various  electronics  for  IF  link  injection  Into  the 
airframe  radar.  The  front  end  for  simulation 
control  has  a  graphics  display  of  what  the 
radar  sees.  The  RTS  is  connected  via  ethernet 
to  the  VAX  8600  and  to  the  F-1 4D  airframe  via 
MIL-STD-1 553B  cables  (to  the  radar  bus)  and 
IF  link. 

(3)  The  airframe  interface  consisting  of  a  Force 
.  CPU-40  processor,  an  Icron  DR11-W  emula¬ 
tor,  and  a  1 553B  bus  interface  board  all  resrd- 
ing  in  a  VME  card  cage.  This  unit  provides  air¬ 
frame  state  vector  and  orientation  data  to  the 


VAX-8600.  The  DR1 1  — W  interface  connects  to 
the  VAX -8600  via  the  two  16-pin  flat  ribbon 
cables  and  the  1 553  bus  interface  connects  to 
the  airframe. 

F-14D  Airframe/Test  Management  Station 
HAAf  Connectivity 

(1)  The  Test  Management  Station  (TMS)  is  the 
“software  pilot"  that  “flies"  the  F-1 4D  airframe. 
The  TMS  provides  the  airframe  equipment 
with  all  the  dynamic  flight  data  necessary  to 
indicate  in  flight  conditions.  The  TMS  is  con¬ 
nected  to  the  airframe  via  MIL-STD-1 553B 
cables  (to  the  mission  computer  and  radar 
buses)  and  various  discrete  connections. 

(2)  The  F-14D  airframe  platform  rece'ives  “flight" 
data  and  characteristics  from  the  TMS  and 
radar  target  data  from-  tfie  RTS.  This  is  an 
actual  F-14D  cockpit  with  all  required  equip¬ 
ment  for  radar  operations  and  analysis. 

Equipment  Present  for  Demonstration.  For 
the  purposes  of  the  demonstration,  the  following 
nonstandard  eqiApmerrt  On  addition  to  the  AlU)  was 
connected  tp*the  ethernet  network  that  provided  the 
interface  betw^n  the  REB-10  and  the  AlU. 

(1)  The  Techriologles  System  Inc.  (TSI)  Low  Cost 
Stealth  was  connected  to  provide  for  both  two- 
and  three-dimensional  displays  of  the  simu¬ 
lated  worid  as  represented  by  the  PDUs 

.  received  oyerthe  network.  This  includes  PDUs 

generkedto  reportthe  position  of  the  SITS  air¬ 
frame  (pseudo  five  aircraft)  and  any  simulation 
entities  being  reported  on  the  network. 

(2)  The  SfMULlZER  was  connected  to  provide  a 
scripted  “target"  generation  capability.  The 
SIMULIZER  would  output  a  scripted  set  of  DIS 
PDUs  on  command  that  represented  one  or 
more  aircraft  flying  a  predetem.ined  route. 

Manned  Right  Simulator 

The  MFS  fadlit/s  mission  is  to  provide,  through 
simulation,  test  and  evaluation  (T&E)  of  aircraft  and 
onboard  aircraft  avionics  systems  and  pilot  training. 
The  MFS  Includes  high-fidelity  flight-dynamics  sys¬ 
tem  simulation,  avionics  system  simulators,  a  wide 
field-of-view  (FOV)  visual  system  for  man-in-the- 
loop  evaluations,  and  a  motion-base  system  to  pro¬ 
vide  acceleration  cues  for  conventional  takeoff  and 
landing  tasks  as  well  as  vertical  and  short  takeoff 
and  landing,  hover,  and  transition.  The  MFS  incor¬ 
porates  four  simulation  stations:  the  motion  base, 
the  dome,  the  laboratory  station,  and  the  crew  sta¬ 
tion  whicli  includes  the  F-1 4  back  seat,  the  F/A-1 8, 
and  the  V-22  Government  Test  Pilot  Trainer.  A 
COMPU-SCENE IV  Visual  Image  Generator  (VIG) 
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system  and  an  IRIS  visual  system  provide  high-  and 
medium-resolution  visuals.  In  addition,  the  dome 
FOV  simulator  provides  two  projectors  for  target 
generation. 

The  dome  with  an  F/A-1 8  and  one  target  generator 
was  used  for  this  POC  demonstration.  The  simula¬ 
tion  program  at  MFS  was  modified  to  accept  DIS 
PDUs  for  target  generation  and  to  output  DIS  PDUs 
from  the  simulation  platform.  The  software  is 
described  in  a  later  section. 

NAWCAD  hardware  connectivity  starts  with  a  local 
NAVNET  node  (T1  tail  circuit).  The  local  NAVNET 
node  feeds  a  56-KBPS  tail  circuit  into  the  MFS  facil¬ 
ity.  From  inside  the  facility,  the  hardware  connection 
from  modem  to  cockpit  simulator  is  described  in  the 
following  paragraphs. 

Network  H/W  Connectivity.  Network  con¬ 
nectivity  consists  of  all  the  following  equipment 
required  to  bring  the  DIS  PDUs  to/from  the  AlU. 


(1)  A  TYTEK  Modem  configured  to  operate  at  56 
KBPS  connects  the  NAVNET  tail  circuit  to 
KG-84AS. 

(2)  Two  KG-84A  point-to-point  data  crypto¬ 
graphic  devices  connect  to  the  two  modems  by 
RS-449  to  RS-449  cable  and  RS-422  to  MIL- 
STD-1 88C  Minimate  connector.  The  RS-499 
connects  to  the  modem  while  the  MIL- 
STD-188C  connects  to  the  “black" 
(encrypted)  connection  on  the  KG-84A.  Two 
KG-84AS  are  needed  as  one  is  connected  to 
SITS  and  the  other  is  connected  to  SISL. 

(3)  A  TIMEPLEX  Minilink  unit  provides  the  link 
between  “phone”  and  computer  communica¬ 
tions.  This  unit  is  connected  to  the  KG-84A  on 
the  “red”  (decrypted)  connection  by  a  MIL- 
STD-188C  to  RS-422  Minimate  connector 
and  from  the  Minimate  to  the  Minilink  by  a 
RS-449  to  Minilink  tempest  cable. 


Figure  2.  NAWCAD  Hardware  Connectivity 
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(4)  A  RAD  REB-20  Ethernet  Bridge  will  pass 
efhernet  packets  to  and  from  each  of  the  NAV- 
NET  connections  and  provide  for  a  dedicated 
thick  ethernet  line  to  the  AID.  This  unit  is  con¬ 
nected  to  the  Minilink  via  an  RS~422  cable. 

AlU  H/W  Connectivity.  The  AID  is  responsi¬ 
ble  for  the  network  interface,  the  managing  of  DIS 
PDUs,  and  the  interface  to  the  Host,  a  Digital  Equip¬ 
ment  Corporation  (DEC)  Micro  VAX  II.  The  AlU  con¬ 
sists  of  a  Force  CPU-40  processor  board  and  a  Bit3 
Qbus-to-VME  adapter  board  with  8-Mbytes  of  dual¬ 
port  RAM,  both  residing  in  a  VME  card  cage.  The 
Bits  card  allows  the  CPU-40  and  a  Micro  VAX  to 
share  one  Mbyte  of  RAM.  The  AlU  Is  connected  to 
the  RAD  REB-20  Ethernet  Bridge  via  a  thick  ether- 
net  cable.  The  Bit3  card  is  connected  to  the  Micro 
VAX  II  by  the  Bit3  supplied  fiat  ribbon  cables;  one  for 
input  and  one  for  output  of  data. 

Cockpit  Simulator  H/W  Connectivity.  The 
cockpit  simulator  consists  of 

(1)  Micro  VAX  (uVax)  providing  the  AlU  “hosT  pro¬ 
cesses.  This  process  manages  the  transfer  of 
DIS  POUs  between  the  AlU  and  multiport 
memory.  The  uVAX  contains  the  Qbus  side  of 
the  Bits  Qbus-to-VME  Adapter  to  the  AlU. 

(2)  uVax  dedicated  for  avionic  simulations.  The 
F/A-18  avionics  models  duplicate  the  func¬ 
tions  performed  by  the  actusd  avionics  in  the 
aircraft.  The  avionics  models  simulate  the 
AYK-14  mission  computers  and  display  pro¬ 
cessors.  The  uVax  simulations  receive/send 
information  fromAo  the  multiport  memory  and 
1553  bus. 

(3)  VAX  8650  used  for  aerodynamic  simulation 
(airframe),  visuals  and  coordinate  conver¬ 
sions.  This  VAX  maintains  a  high-fidelity  aero¬ 
dynamic  model  of  the  F/A-18.  The  visual  pro¬ 
cess  reads  and  processes  incoming  "flat  earth" 
data  from  the  entity  table  in  Multiport  Memory. 
The  coordinate  conversion  process  performs 
transformations  to/from  DIS  world  coordinates 
and  MFS  simulator  flat-earth  coordinates.  This 
VAX  communicates  to  the  Avionic  Simulations 
uVAX  (through  multiport  memory)  and  to  the 
GE  COMPU-SCENE  IV. 

(4)  Multiport  memory  providing  a  common  data 
link  (shared  memory)  to  avionics  and  flight 
dynamics  models. 

(5)  GE  COMPU-SCENE  IV  VIG  system  to  pro¬ 
vide  for  the  visual  environment  in  the  40-foot 
dome  surrounding  the  cockpit  and  target  pro¬ 
jector. 


(6)  uVAX  used  for  communication  with  the  cockpit 
via  MIL-STD-1553  interfaces. 

(7)  fully  functional  cockpit  of  an  F/A-1 8  Hornet. 

Secure  Integration  Simulation  Laboratory 

The  SISL  facility  is  a  secure  environment  for  the 
development,  test,  and  integration  of  the  AlU  soft¬ 
ware.  Access  is  provided  to  development  worksta¬ 
tions,  AlU  hardware,  and  communications  channels 
for  interacting  with  remote  simulations  or  other  AlU 
devices.  The  cryptographic  equipment  allows  inter¬ 
action  with  the  MFS  facilities.  Interactions  between 
SISL  and  SITS  were  constrained  to  go  “through"  the 
MFS  connection  as  described  above. 

SISL  hardware  connectivity  starts  with  a  local  NAV- 
NET  node  (T1  tail  circuit),  which  feeds  a  56-KBPS 
tail  drcuit  into  the  SISL  facility.  The  hardware  con¬ 
nection  inside  the  facility,  from  modem  to  the  labora¬ 
tory  network,  is  described  in  the  following  para¬ 
graphs. 

Network  Hardware  Connectivity.  Network 
connectivity  consists  of  all  the  following  equipment 
required  to  bring  the  DIS  PDUs  toArom  the  labora¬ 
tory  network: 

(1)  A  NEC  Modem  configured  to  operate  at  56 
KBPS  connects  the  NAVNET  circuit  to  a 
KG-84A. 

(2)  A  KG-84A  point-to-point  data  cryptographic 
device  connects  to  the  modem  by  a  V.35  to 
RS-422  cable  and  a  RS-422  to  MIL- 
STD-188C  cable.  The  V.35  connects  to  the 
modem  while  the  MIL-STD-1 88C  connects  to 
the  “black"  (encrypted)  connection  on  the 
KG-84A. 

(3)  A  TIMEPLEX  Minilink  unit  provides  the  link 
between  "phone"  eind  computer  communica¬ 
tions.  This  unit  is  connected  to  the  KG-84A 
“red”  (decrypted)  connection  by  an  MIL- 
STD-1 88C  to  RS-422  cable. 

(4)  A  RAD  REB-1  Ethernet  Bridge  provides  for  a 
dedicated  thick  ethernet  line  to  the  AlU.  This 
unit  is  connected  to  the  Minilink  via  an  RS-422 
cable. 

Laboratory  Network  Equipment.  The  SISL 
facility  contains: 

(1)  Bolt,  Beranek,  and  Newman  (BBN)  Semi-Au- 
tomated  Force  (SAFOR)  system  for  genera¬ 
tion  and  control  of  simulation  entities  and 
transmission  of  the  entities  on  the  network. 

(2)  TSI  Low  Cost  Stealth  for  display  of  two-  and 
three-dimensional  views  of  the  simulated 
world. 

(3)  TSI  translator  for  Simulation  Network  (SIM- 
NET)/DIS  protocols. 


(4)  AID  GenTrack  unit  for  generating  test  entities 
in  either  SIMNET  or  DIS  protocols. 

(5)  Data  logger  for  recording  of  DIS  or  SIMNET 
PDUs  to  allow  playback  and/or  analysis  or 
testing,  demonstrations,  and  exercises. 

NETWORK  CONNECTIVITY  AND  SECURITY 

Long-haul  network  connectivity  and  security  were 
major  issues  during  the  preparation  for  this  POC 
demonstration.  Secured  network  connectivity 
between  the  SITS,  MFS  and  SISL  was  not  estab¬ 
lished  by  the  time  of  the  POC.  The  connectivity 
problems  are  believed  to  be  the  result  of  KG-84A 
“strapping"  problems.  (Each  of  the  four  KG-84As 
needs  to  be  configured  or  “strapped”  before  use. ) 

Originally  the  POC  was  to  use  the  secure  Distrib¬ 
uted  Simulation  Internet  (DSI)  network  to  provide  a 
multipoint  connection  network  with  no  single  point 
of  failure.  However,  the  secure  network  capabilities 
were  not  installed  at  all  three  sites  by  the  time  of  the 
demonstration. 

As  an  alternative,  the  U.S.  Navy's  NAVNET  was 
selected  and  KGf-84As  were  used  as  the  encryption 
devices..  Because  the  KG-84  is  a  point-to-point 
encryption  device,  one  site  must  serve  as  the  “hub" 
of  the  network  and  “forward"  PDUs  for  the  other  two 
sites.  Tlie  MFS  served  as  the  hub  for  the  POC  net¬ 
work.  All  PDUs  generated  at  the  SITS  and  the  SISL 
were  to  be  sent  to  MFS;  MFS  was  to  send  its  PDUs 
to.^th  SI^S  OTd  SISL  In  addition,  MFS  was  to  for- 
aiil  SisL  generated  PDUs  to  SITS  and  forward 
all  SITS  generated  PDUs  to  SISL  However,  this 
setup  was  not  successfully  installed  in  time  for  the 
POC  demonstration. 

The  problems  encountered  in  getting  the  network  in 
place  and  tested  were  the  required  long  lead  time 
for  installing  the  communications  circuits;  develop¬ 
ing  and  getting  approval  of  the  security  procedures 
and  documentation  at  three  sites;  generating  Mem¬ 
orandum  Of  Agreements  (MOAs),  staffing  them 
through  the  local  approval  chains  and  getting  the 
Designating  Approval  Authority  (DAA)  to  sign  off  on 
the  network;  and  getting  the  required  strapping  and 
correct  cabling  at  all  three  sites  as  each  site  has  a 
different  modem. 

As  a  result,  technicians  were  still  trying  to  “strap”  the 
4  KG-84AS,  at  geographically  dispersed  sites  on 
the  day  of  the  POC  demonstration.  Because  of  the 
difficulties  of  coordinating  this  strapping  effort 
between  three  different  commands  in  two  different 
time  zones,  the  secure  network  was  not  success¬ 
fully  established.  Point-to-point  connectivity  was 
successfully  established  among  pairs  of  sites  but 
not  between  all  three  sites  simultaneously. 


SOFTWARE  DEVELOPMENT  AND 
MODIFICATION 

This  effort  required  the  generation  of  new  software 
and  the  modification  of  existing  software.  Software 
for  the  AlU  devices  was  developed  at  NCCOSC  as 
enhancements  and  modifications  of  software  devel¬ 
oped  during  previous  efforts.  The  AlU  hardware 
consisted  of  two  slightly  different  configurations  for 
the  MFS  and  SITS  sites.  The  software  developed 
was  also  slightly  different.  In  addition  to  the  AlU  soft¬ 
ware,  both  MFS  and  SITS  had  to  develop  new  soft¬ 
ware  and  modify  existing  software  to  allow  their  sys¬ 
tems  to  communicate  with  the  AlU  devices. 

SITS  Software 

The  existing  software  was  modified  to  interface  with 
the  AlU.  These  modifications  allowed  the  genera¬ 
tion  of  entities  within  the  RTS  based  upon  Entity 
State  PDUs  (ESPDUs)  received  from  the  AlU.  In 
addition,  the  software  was  modified  to  output  an 
ESPDU  (representing  the  F-14D)  to  the  AIL).  The 
AlU  soft^re  was  modified  to  ignore  events  from 
the  network  (Rre  PDUs,  etc.).  The  AlU  transfers  up 
to  two  ESPDUs  to  the  SITS  system  for  use  in  stimu¬ 
lating  the  RTS. 

SITS  AIU  Software.  The  AlU  reads  and  writes 
DIS  PDUs  to  the  ethernet  port  on  the  Force 
CPU-40  card;  maintains  table  of  entities  and  their 
current  DIS  information,  filters  entities,  transmits 
selected  entities  to  SITS;  ignores  all  DIS  event 
PDUs;  filters  out  and  Ignores  all  non-DIS  ethernet 
packets;  maintains  SITS  F-14D  in  DIS  based  on 
data  received  from  SITS;  emd  tests  entity  genera¬ 
tion. 

The  interface  between  the  AIU  and  SITS  is  main¬ 
tained  by  the  exchange  of  data  at  the  rate  of  four 
times  a  second  (4  Hertz)  via  Direct  Memory  Access 
(DMA)  and  DMA  emulation.  This  is  implemented  by 
the  DR11-W  cards.  The  AIU  and  SITS  read  and 
write  data  to/from  each  other's  memory  via  the 
DR11-W  cards.  The  SITS  performs  actual  DMA 
transfers  while  the  AIU  performs  DMA  emulation. 

The  AIU,  when  interfacing  writh  the  DR11-W  card, 
performs  byte  swapping  and  floating  point  conver¬ 
sions.  The  byte  swapping  is  necessary  when  com¬ 
municating  data  to/from  the  VAX  due  to  different 
processor  architectures.  The  floating-point  conver¬ 
sions  were  required  to  convert  IEEE  floating-point 
representation  in  the  DIS  PDUs  to/from  VAX  float¬ 
ing  point. 

All  DIS  PDUs  that  are  not  ESPDUs  are  ignored.  The 
incoming  ESPDUs  are  first  passed  through  a  filter 
that  drops  any  ESPDUs  that  are  not  located  within  a 
70-mile  cylinder  projected  60  miles  in  front  of  the 
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SITS  F-14D  aircraft  entity.  ESPDUs  that  fall  within 
the  filter  are  then  copied  into  a  hash  table  with  the 
location  determined  by  the  ESPDU  entity  identifica¬ 
tion  field.  Since  the  RTS  can  accommodate  only  two 
targets  per  run.  the  AlU  sends  only  the  first  two 
ESPDUs  it  receives  to  the  RTS. 

The  SITS  system  transfers  an  ESPDU  for  the 
F-14D  to  the  AlU  via  the  DR11-W  interface.  The 
AlU  transmits  the  first  ESPDU  received  from  SITS 
and  then  dead  reckons  the  SITS  entity  and  outputs 
a  new  ESPDU  whenever  the  SITS  entity's  position 
or  orientation  differs  from  the  dead-reckon  values 
by  a  preset  (and  modifiable)  location  and/or  orienta¬ 
tion  threshold.  If  no  positional  threshold  has  been 
exceeded  (i.e.,  no  ESPDU  sent  out )  for  5  seconds, 
then  one  is  output  as  required  by  current  conven¬ 
tion. 

Also,  software  was  built  into  the  AlU  to  allow  gen¬ 
eration  of  a  test  entity.  Through  an  operator  inter¬ 
face,  the  AiU  could  be  instructed  to  generate  an 
ESPDU  for  test  purposes.  This  softwcire  would 
allow  the  generation  of  an  ESPDU  representing  ein 
F-1 4D  aircraft  entity  type  and  allow  modification  of 
the  entities  location;  altitude,  course,  and  speed. 

SITS  System  Software.  The  SITS  system 
software  obtains  F-1 4D  airframe  state  vector  data; 
provides  transformations  of  coordinate,  velocity 
and  orientation  of  the  incoming  and  outgoing  ESP¬ 
DUs;  calculates  RCS  for  all  target  entities:  and  pro¬ 
vides  interface  processing  to  the  airframe,  RTS, 
and  AIU. 

The  SITS  system  software  consists  of  the  airframe 
interface,  the  RTS  interface,  and  the  VAX  process. 
The  airframe  interface  software  was  written  to 
extract  the  airframe  state  vector  data  from  the  mis¬ 
sion  computer  bus  via  a  MIL-STO-1553  interface 
and  send  the  data  to  the  VAX  via  a  DR11-W  inter¬ 
face.  The  RTS  interface  was  added  to  the  existing 
RTS  arid  was  provided  to  receive  target '  '3  data 
from  the  VAX  via  Ethernet, connection  ana  to  use 
this  data  instead  of  the  usual  "canned"  target  data 
that  the  RTS  was  initially  designed  to  use.  The  VAX 
process  ties  the  AIU,  airframe  and  RTS  interfaces 
together. 

The  VAX,  utilizing  modified  software  from  an  exist¬ 
ing  aerodynamic  model,  provides  for  all  coordinate, 
velocity  and  orientation  transformations  and  calcu¬ 
lates  the  target  RCS  data.  The  VAX  also  controls  all 
interface  timing  and  communication  between  the 
VAX  and  the  AIU.  airframe  interface  and  RTS.  The 
VAX  sends  and  receives  ESPDUs  to/from  the  AIU 
via  a  DR11-W  and  receives  airframe  state  vector 
data  from  the  airframe  interface  via  another 


DR11-W  interfaces  and  sends  the  RCS  data  to  the 
RTS  via  ethernet  "thin"  connection. 

MFS  Software 

At  MFS.  the  existing  software  was  modified  to  inter¬ 
face  with  the  AIU.  which  allowed  the  generation  of 
entities  within  the  simulator  based  upon  ESPDUs 
received  from  the  AIU.  The  AIU  software  was  modi¬ 
fied  to  send  the  event  PDUs;  Fire.  Detonation,  and 
Collision.  The  MFS  simulator  software  will  receive 
the  events  but  not  currently  process  them.  In  addi¬ 
tion.  the  software  was  modified  to  output  an  ESPDU 
(representing  the  simulator)  to  the  AIU.  The  AIU 
maintains  a  table  of  all  entities  for  the  MFS  to 
intemogate  and  two  ring  buffers;  one  containing  new 
entity  messages  and  one  containing  events,  and 
outputs  the  simulator's  ESPDU  on  to  the  network. 

MFS  AIU  Software.  The  AIU  reads  and  writes 
DIS  PDUs  to  the  ethernet  port  on  the  Force 
CPU-40  card;  maintains  a  table  of  entities  and  their 
current  DIS  information;  passes  new  entity  notifica¬ 
tions  to  MFS;  pcisses  DIS  Rre,  Detonation,  and  Col¬ 
lision  event  PDUs  to  MFS;  filters  out  and  ignores  all 
non-DIS  ethernet  packets;  mantains  MFS  simula¬ 
tor  in  DIS  based  on  data  received  from  MFS;  and 
generates  test  entity. 

The  interface  between  the  AIU  and  MFS  is  main¬ 
tained  by  data  located  in  shared  memory  and  is 
implemented  by  the  BIT-S  cards.  The  AIU  and  MFS 
read  and  write  data  to  a  dual  port  memory  main¬ 
tained  on  the  VME  side  of  the  BIT-S  cards.  The 
MFS  interfaced  with  the  memory  on  its  BIT-3  card 
in  the  same  manner  as  it  interfaces  with  normal  VAX 
memory.  The  AIU  interfaced  with  its  BIT-3  memory 
card  in  the  same  manner  as  any  offboard  (nonlocal) 
VME  memory  with  the  exception  of  data  represen¬ 
tation. 

The  AIU,  when  interfacing  with  the  BIT-3  card,  per¬ 
forms  byte  swapping  (necessary  when  communi¬ 
cating  data  to/from  the  VAX  due  to  different  proces¬ 
sor  architectures),  and  floating-point  conversions 
(required  to  convert  IEEE  floating-point  representa¬ 
tion  in  the  DIS  PDUs  to/from  VAX  floating  point  for- 
mat) 

In  the  BIT-3  memory,  the  AIU  maintains  a  table  of 
1033  "slots"  for  input  DIS  entities.  Entities  are 
inserted  into  the  table  based  on  a  hashing  algo¬ 
rithm.  When  a  new  entity  is  received  from  the  net¬ 
work,  its  entire  ESPDU  is  inserted  in  the  table  and 
the  MFS  notified  by  a  message  in  a  ring  buffer  (also 
in  BIT-3  memory).  When  a  new  ESPDU  is  received 
for  an  existing  entity,  the  data  overlay  the  existing 
ESPDU.  The  MFS  can  interrogate  individual  entries 
in  the  table  whenever  it  requires  data.  The  AIU  dead 
reckons  table  entries  by  updating  location  and  time 
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stamp  information  in  the  table  approximately  10 
times  a  second. 

Aiso  in  the  BIT-3  memory  is  a  table  maintained  by 
the  MFS  with  19  slots  for  MFS  entities.  The  MFS 
updates  these  entities  at  its  own  processing  rate. 
Three  ring  buffers  in  BIT-3  memory  transfer  event 
data;  one  for  each  direction  and  one  for  notification 
of  new  ESPDUs  to  MFS.  The  ring  buffers  are  main¬ 
tained  as  first-in-first-out  (FIFO)  queue  with  the  old¬ 
est  message  being  overiaid  in  the  event  of  buffer 
overflow.  All  DIS  PDUs  that  are  not  ESPDUs  are 
inserted  into  the  to  MFS  ring  buffer  when  received. 
A  second  ring  buffer  transfers  event  PDUs  from  the 
simulator  to  the  AlU.  The  third  ring  buffer  passes 
indications  of  new  ESPDUs  received  by  the  AlU  to 
the  MFS. 

The  AlU  transmits  an  ESPDU  at  the  first  encounter 
in  the  MFS  entity  table.  The  AlU  dead  reckons  the 
MFS  entity  ba^  upon  the  ESPDU  and  outputs  a 
new  ESPDU.  whenever  the  MFS  entity’s  position  or 
orientation  differs  from  the  dead  reckoned  values  by 
a  ;  pre^t  (and  modifiable)  location/orientation 
threshold.  If  no  threshold  has  been  exceeded  (i  e-. 
no  ESPDU p^ut)  for  5  seconds,  then  an  ESPDU  is 
output-  Software  built  into  the  A|U  allows  generation 
of  test  entiti^.  An  operator  interface  would  allow 
the^^ftware  to  generate  ESPDUs  representing  a 
user  specified  entity  type  at  a  user  specified  loca¬ 
tion,  attitude,  course,  and  speed. 

Simula- . 

tor  softw^  obtains  incoming  event  and  entity  state ' 
PDUs  from  the  AlU  places  them  in  multiport 
memory,  and  provides  transformations  of  coordi¬ 
nate,  velocity,  and  orientation  of  the,  incoming  and 
outgoing  ESPDUs. 

Ttie  host  process  software  provides  the  MFS  inter¬ 
face  to  the  /»!U,  retrieves  the  incoming  DIS  PDU 
data  arid  puts  it  into  the  multiport  memory,  extracts 
local  entity  data  and  events,  and  places  the  data 
into  the  AlU  shared  memory.  The  visual  process 
reads  the  entity  table  in  the  multiport  memory, 
applies  coordinate  transformations  to  flat  earth,  and 
provides  the  GE  COMPU-SCENE IV  with  the  entity 
data  for  target  generation.  The  local  entity  process 
performs  coordinate  transformations  on  the 
F/A-1 8-state  vector  data  and  provides  this  data  to 
the  multiport  memory,  which  is  read  by  the  host  pro¬ 
cesses. 

TEST  AND  INTEGRATION  EFFORTS 

Individual  pieces  were  tested  separately  to  the 
extent  possible.  Next,  the  AlU  was  installed  at  the 
MFS  site  and  integration  testing  with  the  MFS  sys¬ 
tem  was  performed.  By  using  the  lessons  learned  at 


MFS.  the  AlU  was  installed  and  integrated  into  the 
system  at  SITS.  However,  a  communications  net¬ 
work  had  to  be  established  and  approved  for  secure 
operations  before  full  system  integration  could  be 
accomplished.  The  available  time  expired  before 
the  network  was  successfully  used  as  a  transparent 
encrypted  communication  medium. 

SITS  Testing 

SITS  testing  consisted  of  installing  the  AlU,  estab¬ 
lishing  DR11-W  communications,  defining  proper 
data  representation  (byte  swapping  and  floating 
point  formats),  and  the  sending  and  receiving  of 
ESPDUs.  Interaction  of  the  AlU  operating  system/ 
CPU  board  interaction  with  the  Icron  DR  1 1  -W  em  u- 
lator  board  resulted  in  timing  problems  that  took  up 
the  bulk  of  the  AlU/SITS  interface  testing.  Proper 
data  representation  was  accomplished  utilizing 
builtH'n  test  DIS  PDUs. 

To  facilitate  testing  without  input  from  the  network, 
the  AlU  was  modified  to  generate  a  F-1 4D  ESPDU, 
which  was  injected  at  the  network  handler  level  so 
as  to  appear  to  the  AlU/SITS  as  a  real  entity.  The 
test  ESPDU  was  successfully  displayed  on  the 
F-14DAPG-71  radar. 

A  second  means  of  generating  an  ESPDU  was 
brought  online  by  the  Unix  Workstation  based 
SIMULIZER.  The  SIMUUZER  generated  ESPDUs 
following  a  predetermined  script,  which  proved  use¬ 
ful  for  t^rig  consistent  fixed  flight  patterns. 

SITS  testing- also  Included  F-14D  *Yollour  exer¬ 
cises  where  the  SITS  doors  were  opened  and  the 
cockpit  was  rolled  out  to  allow  the  radar  to  actively 
radiate.  Due  to  close  proximity  to  major  airports, 
many  “targets  of  opportunity"  were  available  for 
tracking,  which  allowed  for  a  variety  of  “real”  vs. 
“simulated"  r  :dar  operations. 

MFS  Testing 

MFS  testing  consisted  of  installing  the  AlU,  config¬ 
uring  the  BIT-3  cards,  defining  proper  data  repre¬ 
sentation  (byte  swapping  and  floating  point  formats) 
and  the  sending  and  receiving  of  ESPDUs.  Config¬ 
uring  the  BIT-3  required  some  calls  to  the  BIT-3 
corporation.  Proper  data  representation  was 
accomplished  utilizing  built-in  test  DIS  PDUs. 

To  facilitate  testing  without  input  from  the  network, 
the  AlU  was  modified  to  generate  an  operator  speci¬ 
fied  entity  and  allow  operator  dynamic  interaction. 
The  ESPDUs  injected  at  the  network  handler  level, 
appeared  to  the  AlU/MFS  as  real  entities,  which 
proved  to  be  invaluable  in  MFS  testing  as  no  net¬ 
work  traffic  was  available.  Utilizing  these  test  ESP¬ 
DUs,  target  visuals  were  successfully  displayed  in 
the  simulator  dome. 
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MFS  testing  also  included  “wrapping  around"  the 
F/A-t8  MFS  entity  with  an  offset  back  to  the  target 
'  generator.  Thus,  the  AlU/MFS  loop  was  tested  with 
i  the  target  visual  acting  as  a  wingman  following  the 
F/A-1  8  movements. 

AlU  Testing 

Both  AlU  systems,  with  the  exception  of  correct 
byte  swapping,  were  extensively  tested.  A  “host" 
process  was  designed  and  coded  to  run  on  a  sepa¬ 
rate  processor  board  to  simulate/stimulate  the  SITS 
DR11-W  interface  and  VAX  host  process.  For  the 
MFS.  a  host  process  board  and  a  shared  memory 
board  were  used  to.test  the  AiU  against  the  shared 
^  memory,  ring  buffers,  and  VAX  host  processes. 
.  j  ArkJther  separate  processor  board  AIU  with  DIS 
1  generation  capabilities  ^  aJ ong  with  built-in 
-'  K  gerierators  were  used  to  generate 

■•4 ioOTming  and  outgoing  F|DUs.  “CannecT  DIS  PDUs 
built  into  each  AIU  expressly  for  byte  sw^- 
lipiM^ng. 


JISISLTe^ng 

^|^^;^the^SISL  Iat^^^_  occurred  in  stages: 

'  (if  ^Rnal  connect!^  checks  t^tween  all  systernS 
occurred. 

-  BBN  SAFOR  to  TSI  (SIMNET  6.6.1  pro- 
'  tbcol) 

GenTrack  to  Data  Logger  (DIS  1 .0  prbto- 
coQ 

-  Data  Logger  to  TSI  (DIS  1.0  protocol) 

(2)  Once  all  connections  were  verified,  a  F-14D 
was  created  on  the  S^OR  workstation  and 

..  rec&fA  of  the  PDUs  checked  at  all  other 
devices.  This  test  failed  because  the  TSI  trans¬ 
lator  was  not  functioning  properly. 

(3)  DIS  F-1 4D  aircraft  was  verified  to  be  sending 
out  to  the  network  but  time  limitations  and 
security  problems  precluded  a  full  scale  test 

End-to-End  System  Integration 


The  -goal  was  to  establish  a  secure  network 
between  SITS,  MFS,  and  SISL  and  then  show  Inter¬ 
action  between  all  entities  operating  concurrently. 
The  first  step  was  to  establish  the  secure  commu¬ 
nications  network  that  would  be  transparent  to  the  • 
systems  using  it.  Overall  systems  i.  .egrations  test¬ 
ing  could  be  performed  in  accordance  with  the 
“Naval  Air  Warfare  Center  Aircraft  Division  (NAW- 
CAD)  and  the  Naval  Air  Warfare  Center  Weapons 
Division  (NAWCWD)  IGSS  Lab  Assessment  and 
Procedures.”  The  unsecured  network  communica¬ 


tions  were  established  and  verified  using  the  AIU 
PDU  generation  facilities  at  MFS  and  SITS,  the 
BBN  SAFOR  PDU  generation  facilities  at  SISL,  the 
TSI  Low  Cost  Stealth  for  display  at  SISL  and  SITS, 
and  the  MFS  dome  simulator  for  display  at  MFS. 
Attempts  were  made  to  establish  secure  commu¬ 
nications  between  all  three  sites  using  the  same 
equipment  to  transmit  and  verify  receipt  of  PDUs. 
Two-way  secure  communications  were  established 
between  SISL  and  MFS  and  between  MFS  and 
SITS.  Three-way  communications  were  not  suc¬ 
cessful,  which  meant  integration  testing  was  not 
possible. 

PROOF-OF4iONCEPT  DEMONSTRATION 

/*. 

The  HYDY  Phase  I  POC  (November  1992  at 
NAWCWD)  consisted  of  an  In-Progress-Review 
covering  both  what  had  been  accomplished  for 
pha  ^  I.  plans  for  phase  II,  and  demonstrations  in 
me  SITS  laboratory.  Simultaneous  radar  stimula¬ 
tion  with,  simulated  and  real  targets  was  the  main 
goal  for  HYDY  Phase  1  and  was  successfully  dem¬ 
onstrated.  The  SITS  F-14D  airframe  was  “rolled 
out"  on  both  days  of  the  POC  demo  to  allow  the 
;i^Gr71.radar  to  actively  radlatejor  det^on  of  live 
aircraft.  The  two  simulated  targets  were  generated 
by  the  SITS  AIU  and  the  SIMUUZER. 

The  first  day  rollout  was  marred  by  a  loo^  ISMbus 
conrtection  at  the  airframe.  The  bad  connection 
cau^  noise  on  the  line  that  wreaked  havoc  with 
^  tire  interface  to  the  TMS  (the  program  tl^i!flj^“;the| 
F-14D  airframe),  and  the  RTS.  The^  prograrns 
would  not  run  long  due  to  lack  of  stable  data  from 
me  frame.  Eventually,  a  simulated  target  success¬ 
fully  injected  into  me  radar  receiver  resulted  In  me 
track  displayed  on  me  Radar  Intercept  Operator 
(RIO)  console. 

The  second  day  rollout  was  more  successful  Simu¬ 
lated  tracks  (two)  along  wfth  real  aircraft  were 
tracked  on  me  RIO  ix)nsoIe.  The  simulated  tracks 
were  tun  through  a  variety  of  course  and  speed 
changes  (altitude  was  not  clianged).  The  live  air¬ 
craft  flew  “race  track"  patterns  wim  a  long  leg  com¬ 
ing  in  off  me  ocean  directly  at  the  SITS  laboratory. 
This  flight  path,  repeated  at  regular  intervals,  made 
it  possible  to  generate  a  simulated  entity  that 
appeared  to  be  flying  with  the  live  aircraft  and 
showed  the  simultaneous  detection  and  tracking  by 
the  F-14D  radar  of  both  live  and  simulated  aircraft. 
The  demonstration  showed  no  detectable  differ¬ 
ence  between  the  radar  returns  of  a  real  aircraft  and 
a  simulated  aircraft. 

The  lack  of  a  secured  line  prevented  the  MFS  dome 
simulator  from  providing  a  manned  simulator  to 
stimulate  the  SITS.  The  network  demonstration 
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was  to  have  the  two  facilities,  SITS  and  MFS,  “fly“ 
against  each  other.  An  example  scenario  would 
have  put  the  MFS's  F/A-1 8  cockpit  BVR  in  front  of 
the  SITS  F-1 4D  airframe  with  a  closing  course  for  a 
fly  by.  The  F-14D  would  pick  up  the  F/A-1 8  as  a 
track  on  its  radar  and  the  MFS  would  visually  dis¬ 
play  the  F-1 4D  when  the  aircraft  came  within  visual 
range.  As  it  turned  out.  both  sites  had  to  fly  against 
locally  generated  AlU  DIS  aircraft  entities.  "Tie  AlU 
provides  the  DIS  network  compatibility  required  for 
each  of  the  sites  and  has  a  built-in  test  function  tiiat 
allows  them  to  generate  a  variety  of  DIS  entities. 

FUTURE  EFFORTS 

Once  the  secure  communications  network  is  fully 
functional,  the  testing  and  integration  will  be  com¬ 
pleted.  Work  will  continue  toward  building  a  more 
robust  AlU’by  using  the  lessons  learned  during  this 
effort  arid  research  in  other  areas. 

The  (effort  to  interfa(ce  with  the  F-1 4D  RADAR  sys- 
tetT)  will  continue  with  the  development  of  an  ^r- 
bome  RTS'(ARTS).  This  effort  will  reduce  the  size 
of  the  current  RTS  and  combine  the  functionality  of 
the  AtU  into  the  ARTS  hardware  suite.  The  airborne 
versiori  of  the  AlU  will  be  modified  to  accept  input 
from  a  radio  receiver  vice  an  ethemet  input.  The 
PDUs  received  by  the  radio  will  be  communicated  to 
the  ARTS  via  a  1 5S3B  bus.  The  content  of  the  ESP- 
DUs  will  be  modified  because  of  the  limited  band¬ 
width  qf  j^e  transmission  hardware.  Current  plans 
.-jcall  fo^^;RPU;«tri^ure>to  reflect  the  design  put; 
forth  In  “Arial^'s  of  DIS  Protocols  for  DARPA’S 
HYDY  Project"  The  generation  of  the  ESPDU  rep¬ 
resenting  the  live  aircraft  will  be  done  by  a  ground 
statio'*  using  current  Tactical  Aircrew  Combat  Train¬ 
ing  System  (TACTS)  range  ground  station  technol¬ 
ogy  and  in  the  ar  by  the  airborne  AlU.  The  ground 
station  will  serve  as  an  AlU  for  airoome  entities  out- 
puting  full  DIS  ESPDUs  for  the  aircraft,  filtering 
received  PDU  traffic,  formatting  PDUs  for  transmis¬ 
sion  to  the  arcraft,  and  conveying  the  PDUs  to  the 
radio  for  transmission. 

In  parallel  with  the  above  effort,  the  secure  network 
will  be  established.  The  three  sites  will  be  integrated 
and  used  to  perform  data  latency  testing  to  deter¬ 
mine  the  effects  of  transmission  delays  over  long 
distances  when  using  high-fidelity  simulations.  This 
may  result  in  further  changes  or  enhancements  to 
the  AlU  to  mitigate  any  deleterious  affects  of  trans¬ 
mission  delays. 

REFERENCE 

“Military  Standard  Version  1.0  (Draft)  -  Protocol 
Data  Units  for  Entity  Information  and  Entity  Interac¬ 
tion  in  a  Distributed  Interactive  Simulation,"  Institute 


for  Simulation  and  Training.  University  of  Central 
Florida,  October  1992. 

ACRONYMS 

AlU-Advanced  Interface  Unit 
ARPA-Advanced  Research  Projects  Agency 
ARTS-/Surborne  RTS 
BBN-Bolt,  Beranek,  and  Newman 
BVR-Beyond  Visual  Range 
DAA-Designating  Approving  Authorih; 
DIS-Distributed  Interactive  Simulation 
DMA-Direct  Memory  Access 
DSI-Defense  Simulation  Internet 
ECM-Electronic  Counter  Measures 
ESPDU-Entity  State  PDU 
FOV-Field-of-View 

HYDY-Highly  'dynamic  Vehicles  in  a  Real  and  Syn¬ 
thetic  Environment 
IF-Intermediate  Frequency 
IGSS-Intelligent  Gateway/Scaleable  Simulation 
IPR-Irv-Progress-Revew 
KBPS-Thousand  Bits  Per  Second 
LAN-Local  Area  Network 
MBPS-Million  Bits  Per  Second 
MFS-44anned  Right  Simulator 
MOA-Memorandum  of  Agreement 
NAVNET-Navy  Network 

NAWCAD-Naval  Air  Warfare  Center  Aircraft  Divi¬ 
sion 

NAWCWD-Naval  Air  Warfare  Center  Weapons 
'Division  . 

NCCOSC-Naval  Command,  Control  and  Ocean 
Surveillance  Center 
PDU-Protocol  Data  Unit 
POC-Proof-of-Concept 
RCS-Radar  Cross  Section 
RDT&E-Research,  Development,  Test  and  Evalu¬ 
ation 

PF-Radio  Frequency 
RTS-Radar  Target  Stimulator 
RWR-Radar  Warning  Receiver 
SAFOR-Semi-Automated  Forces 
SIMNET-Simulation  Network 
SISL-Secure  Integration  Simulation  Laboratory 
SITS-System  Integration  Test  Station 
STRICOM-Simulation,  Training,  and  Instrumenta¬ 
tion  Command 

TACTS-Tactical  Aircrew  Combat  Training  System 
TMS-Test  Management  Station 
TSI-Technologies  Sysiem  Inc. 

V/sX-Virtual  Address  Extension 
VIGf-Visual  Image  Generator 
VME-Versa  Modula  Europa 
WAN-Wide  Area  Network 
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The  Proceedings  o1  {he  15th  Interservice/Industry  Training  Systems  and  Education 
Conference  (l/ITSEC)  contain  all  papers  to  be  presented.  The  success  of  poster  displays 
led  us  to  a  specific  session  allocated  to  poster  papers.  This  allows  authors  to  provide  an 
in-depth  discussion  of  their  research. 

This  year's  papers  are  presented  In  six  tracks. 

Policy  and  Management 

Education,  Instruction  and  Training  Methodology 

Training,  Development  and  Delivery 

Modeling  and  Simulation 

Simulation  and  Training  Systems 

R&D  Technology  Applications 

The  Conference  Committee  listed  on  the  following  pages  devote  a  great  deal  of 
time  and  effort  to  make  this  conference  a  success  and  they  have  my  sincere  appreciation. 
Each  year  we  try  to  present  innovative  approaches  and  solutions  to  current  problems. 
Please  share  your  ideas  for  future  conferences  by  completing  the  forms  provided  in  each 
session. 

On  behalf  of  the  entire  committee  we  hope  you  enjoy  the  conference. 


Judith  Shellnutt-Riess 
Program  Chair 
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